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(54) Data transfer method, apparatus, and recording medium for use in hierarchical system 



(57) In a hierarchical network configuration, if trans- 
fer of data such as requirements and responses there- 
from and thereto are executed in a relay manner 
between plural manager systems and managed sys- 
tems on network routes, the requirements and the 
responses are duplicated in each manager system, 
thereby presenting a problem of increased amounts of 
data transfer on the network The present invention that 
prevents the data transfer amounts from increasing not 
only on one route but also on plural routes solves this 
problem by determining whether to update data on the 
basis of names of manager system in upper layers, 
route information and so forth. 



FIG.1 




MANAGER SYSTEM (CLIENT) 



SUBMANAGER SYSTEM 1 



SUBMANAOER SYSTEM 2 



SUBMANAGER SYSTEM 3 



SUBMANAGER SYSTEM N 



MANAGER SYSTEM (SERVER) 




CM 
< 

CO 
CM 



Q. 
LU 



Printed by Xerox (UK) Business Services 
2.167 (HRSV3.6 



EP 1 024 43ft A2 



2 



Description 

[0001] The present invention relates generally to a 
data transfer method, a data transfer apparatus, and 
data recording medium for use in hierarchical systems, s 
[0002] Referring to FIG. 1 , there is shown a system 
in which a managed system returns static information 
(namely, unique information having little change in 
result) to a requirement by a manager system for infor- 
mation acquisition. To be more specific, an information w 
acquisition requirement by a manager system (101) is 
sent to a managed system (106) through submanager 
systems (102 through 105) in a relay manner. 
[0003] Likewise, a response result to the informa- 
tion acquisition requirement is also returned to the man- is 
ager system through the submanager systems in a 
relay manner. At this time, an information acquisition 
requirement and its response result are not transferred 
over different routes. 

[0004] Referring to FIG. 2, each of the submanager 20 
systems (202 through 205) is composed of a manager 
capability and a submanager capability and may issue 
an information acquisition requirement like the manager 
system, performing the same information acquisition 
requirement operation as with the case of the manager 25 
system. One example of a system having the above- 
mentioned characteristics is a system in a hierarchical 
configuration for acquiring the property information on a 
submanager system from a manager system as shown 
in FIG. 3. 30 
[0005] H a manager system and submanager sys- 
tems issue a same information acquisition requirement 
to a managed system, the same information acquisition 
requirement and its reply result flow on a route multiple 
times, causing redundancy (in the portions in which the 35 
arrows of information acquisition requirement and its 
replay result overlap as shown in FIG. 1) and some- 
times overloading the network. 
[0006] Preferably, in order to solve the above-men- 
tioned problems, the present invention executes the tol- 40 
lowing means. If an information acquisition requirement 
is made from the manager system to a managed sys- 
tem, it is determined in the submanager systems on the 
routes to that managed system whether or not to issue 
a same information acquisition requirement 45 
[0007] Preferably, rf the same information acquisi- 
tion requirement is to be issued, it is recognized in 
advance in the submanager systems. When the infor- 
mation acquisition requirement was received by the 
managed system and it has returned a response result, so 
the submanager systems acquire the response result if 
it is necessary, and pass the response result to the 
manager system. 

[0008] This configuration can prevent same data 
from flowing over a route in a duplicated, redundant ss 
manner. In addition, by having each submanager sys- 
tem store in advance the response results for particular 
information acquisition requirements, the submanager 



system can pass the stored response result to a partic- 
ular information acquisition requirement to the manager 
system or a submanager system in an upper layer that 
issued the requirement. Consequently, this configura- 
tion reduces the data traffic on the route from that sub- 
manager system to the managed system. 

Brief description of the drawings 

[0009] These and other objects of the invention will 
be seen by reference to the description, taken in con- 
nection with the accompanying drawing, in which: 

FIG. 1 is a diagram illustrating the configuration of a 
system to which the present invention is applicable 
and the flows of data transfer; 
FIG. 2 is a diagram illustrating the configuration of a 
system to which the present invention is applicable; 
FIG. 3 is a diagram illustrating one example of a 
system configuration for managing property infor- 
mation in a multi-layer system; 
FIG. 4 is a diagram illustrating a state in which each 
of the manager system and submanager systems 
has items; 

FIG. 5 is a diagram illustrating a method of merging 
items in each of the manager system and subman- 
ager systems; 

FIG. 6 is a diagram illustrating a method of updating 
property information in each of the manager system 
and submanager systems; 
FIG. 7 is a diagram illustrating the structure of a DB 
having attributes; 

FIG. 8 is a diagram illustrating the configuration of a 

program in the manager system; 

FIG. 9 is a diagram illustrating one example of the 

item edit screen in the manager system; 

FIG. 10 is a flowchart indicative of item editing; 

FIG. 1 1 is a flowchart continued from the flowchart 

of FIG. 10; 

FIG. 12 is a diagram illustrating the initial state of 
items of each of the manager system and subman- 
ager systems; 

FIG. 13 is a diagram illustrating a state in which 
items are initialized; 

FIG. 14 is a diagram illustrating a state in which 
items are merged; 

FIG. 15 is a flowchart indicative of the merge 
processing; 

FIG. 16 is a diagram illustrating a state in which 

property information is updated; 

FIG. 17 is a flowchart indicative of the update 

processing; 

FIG. 18 is a diagram illustrating a state in which 
items are initialized; 

FIG. 19 is a diagram illustrating a state in which 
items are merged; 

FIGS. 20 and 21 are flowcharts indicative of the 
merge processing; 
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FIG. 22 is a diagram illustrating a state in which 
Kerns are initialized; 

FIG. 23 is a diagram illustrating a state in which 
items are merged; 

FIG. 24 is a flowchart indicative of the merge 
processing; 

FIG. 25 is a diagram illustrating a state in which 

property information is updated; 

FIG. 26 is a flowchart indicative of the update 

processing; 

FIG. 27 is a diagram illustrating a state in which 
Hems are initialized; 

FIG. 28 is a diagram illustrating a state in which 
Hems are merged; and 

FIG. 29 is a diagram illustrating a state in which 
property information is updated. 

Detailed description of preferred embodiments 

[0010] This invention will be described in further 
detail by way of example with reference to the accompa- 
nying drawings. For embodiments of the invention, sys- 
tems are used for example for managing the property 
information of managed systems in a multilayer network 
environment as shown in FIG. 3 (although not shown in 
FIG. 3. business hubs such as business offices, 
branches, and sales offices and the departments in 
each of these hubs also have multiple submanager sys- 
tems and managed systems) . It is assumed here that 
the submanager systems in the multilayer network envi- 
ronment be subordinate to the manager system and the 
submanager systems in every layers does not depend 
on the information about the other submanager systems 
in that layer. The following outlines the flow of process- 
ing. 

[0011 J Now, referring to FIG. 4 t the items of infor- 
mation required by the manager system and the sub- 
manager systems in every layers are defined. Next, as 
shown in FIG. 5, the manager system issues an infor- 
mation acquisition requirement, and by repeating the 
merging of the items of required information and down- 
loading item files in the submanager systems, the man- 
ager system requires information from the managed 
system. 

[001 2J Referring to FIG. 6, a file containing the 
result of property information inputted in the managed 
system is uploaded into the manager system through 
the submanager systems. In the course of this upload- 
ing, each submanager system updates the information 
with respect to the items defined by itself and uploads 
the other items to the upper submanager system. 
[001 3] It should be noted that the embodiments are 
property information managing systems as described 
above, but the present invention is also applicable to 
systems that handle other kinds of information to be 
required for acquisition. 



Embodiment 1 : 

[0014] Referring to FIG. 8, there is shown a block 
diagram of the program in each submanager system. 
s The submanager system comprises a main manager 
program (802), a merge processing block (hereafter 
referred to as merge-process) (805) that receives an 
item file composed of item groups downloaded from the 
upper-layer manager system and merges the received 
io items, an update processing block (hereafter referred to 
as update-process) (804) that receives a result file com- 
posed of the items and property information from the 
lower-layer system (the lower-layer manager system or 
the managed system) and updates the property infor- 
ms mation, an edit processing block (hereafter referred to 
as edit-process) (803) that edits items managed in its 
own system, a user terminal (801) on which information 
display and operation are executed, and a DB (Data- 
base) (806) storing the items and property information. 
20 The structure of the DB is as shown in FIG. 7 in which 
each item has an attribute field. 
[001 5] To this attribute field, one of three statuses is 
set: "0" an item managed by the system in a current 
layer (hereafter also referred to as "this system") indica- 
25 tive that the item is managed in the layer of this current 
system; "1" an item managed by upper system indica- 
tive that the item is managed by the upper system; and 
"2" a common item indicative that this item is common 
to this system and the upper system. Basically, the sub- 
30 manager system in each layer can be realized by the 
similar configuration to that of the submanager systems 
in the other layers. However, the program of the man- 
ager system at the top of the multilayer environment has 
no merge-process. 
35 [0016] All the processing operations mentioned 
above can be executed in concurrently. In the concur- 
rent processing, there is a time in which DB update- 
processes overlap. It is assumed that this portion of 
overlapped time is exclusively controlled in advance 
40 (this, however, is omitted from the description of the 
processing flow below). 

[0017] First, edit-process is described. In edit-proc- 
ess, the contents of the DB of this system are displayed 
and edited. For displaying the property information 

45 stored in the DB, only the items other than those man- 
aged by the upper system are displayed. 
[0018] The output of edit-process can also be 
directed to a file or a printer in a free form in addition to 
the display device of the user terminal. In edit-process, 

so addition and deletion of items and attribute change of 
items can be performed. FIG. 9 shows one example of 
the edit screen. FIGS. 10 and 1 1 show flowcharts indic- 
ative of the edit operation. A list of items and their 
attributes are displayed on the display device of the user 

55 terminal (S301) and the system wait for an input opera- 
tion by the user (S302). 

[0019] When the edit operation has been com- 
pleted and the end thereof is instructed by the user 
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(5303) , this system extracts the Items from the DB of 
this system and downloads the item file containing the 
extracted items to the lower submanager system or the 
managed system directed connected to this system 

(5304) , upon which the editing is ended. If no editing 5 
has been performed, the file downloading is not per- 
formed. If the addition of an item is instructed (S305), 
this system adds the specified item to its DB, specifies 
the attribute of the added item as the item managed by 
this system ("0") (S306), and waits for another operation w 
to be inputted by the user (S302). If the deletion of an 
item is instructed (S307), this system deletes the speci- 
fied item from its DB directly provided that the attribute 

of the item to be deleted is the item managed by this 
system ("0") (the property information is also deleted if 75 
it is set for the item) (S309). If the attribute is the item 
managed by upper system ("1"), this system outputs an 
error message (S311). If the attribute is the common 
item ("2"), this system changes the attributes to the item 
managed by upper system (T) (S310). 20 
[0020] When the above-mentioned processing has 
been completed, this system waits for an operation to 
be inputted by the user (S302). If the change of an item 
attribute is instructed (S312), the attribute of that item is 
changed from the item managed by upper system ("1 ") 25 
to the common item ("2"), or if the instruction is vice 
verse, the attribute of that item is changed (S314) from 
the common item {"2") to the item managed by upper 
system p"). outputs error message (S315) and waits 
for operation to be inputted by the user. 30 
[0021] Where other instruction other than those 
stated above, this system outputs error message (S316) 
and waits for operation to be inputted by the user 
(S302). It is practicable to determine particular button 
operations that will cause an error and deactivate the 35 
buttons concerned in advance to prevent the user from 
operating them. 

[0022] The following describes merge-process with 
reference to the transition diagrams shown in FIGS. 12 
through 14 and the flowchart shown in FIG. 15. It is 40 
assumed that merge-process is performed in a lower 
manager system shown in the transition diagrams. In 
the initial state, this manager system is waiting for the 
downloading of data from the upper manager system or 
the manager system (S001). At this moment, the items 45 
in the DBs of the upper and lower manager systems are 
as shown in FIG. 12. 

[0023] It should be noted that, for the convenience 
of description, the items from the upper manager sys- 
tem have already been prepared in the lower manager so 
system (items A through C and F). 
[0024] First, when an item file has been down- 
loaded from the upper manager system, this lower man- 
ager system deletes all items having the attribute of the 
item managed by upper system ("1 ") (S002). Next, this 55 
system changes the common item CO") to the item man- 
aged by this system fO") (S003). The states of the 
items in the DBs of the upper and lower manager sys- 



tems are shown in FIG. 13. 

[0025] Then, this lower manager system opens the 
downloaded item file (1304) and reads the items 

(5004) . When all items have been read from the item file 

(5005) , this system prepares an item file containing the 
extracted item data from its own DB and downloads the 
prepared item file to the directly connected submanager 
system or managed system ($008) in lower layer and 
waits for another downloading operation (S008 to 
S001). 

[0026] This submanager system reads the items 
one by one in the item file (1304) and checks its own DB 
for any same item (S006). If the same item is found, this 
system updates its DB by changing the attribute of the 
same item to the common item ("2") and starts reading 
the next items (S009 to S004). If there is no same item, 
this system adds the read items to its DB and sets the 
attribute of the read item to the item managed by upper 
system p") and starts reading the next Hems (S007 to 
S004). 

[0027] FIG. 14 shows one example of the DB 
update operation performed in accordance with the 
flowchart of merge-process. As shown, item A, item B, 
and item C are downloaded to this system (lower man- 
ager system) from its upper manager system to be 
merged with item C, item D, and item E held in this sys- 
tem, the result of merge-process being displayed in the 
after-change table. Then, item C through item B are 
downloaded to the system in further lower layer con- 
nected to this system. 

[0028] The following describes update-process with 
reference to the transition diagrams shown in FIGS. 14 
and 16 and the flowchart shown in FIG. 17. In the initial 
state, this system is waiting for the uploading of a result 
file from its lower-layer system (S101). The state of the 
items of the DB of this system is as shown in the after- 
change table shown in FIG. 14. 
[0029] First, this system opens the uploaded result 
ffle 1 (1606) and reads the items and property informa- 
tion contained in the file (S102). Next, this system 
searches its DB for the read item. If the attribute of the 
detected item is the item managed by upper system 
(T) (S104), then this system writes the item and the 
property information in the result file 1 to a result file 2 
(1605) to upload it to the upper manager system (S105) 
and starts reading next item and property information 
(S102). H the attribute of the detected item is other than 
the item managed by upper system ("1") (S104), this 
system updates the property information of the item 
concerned in the DB of this system (S107). 
[0030] If the attribute of the detected item is the 
common item ( n 2 w ) (S108), this system writes the item 
and property information in the result file 1 (1606) to the 
result file 2 (1605) to upload it to its upper manager sys- 
tem and starts reading next item and property informa- 
tion (S102). When this system has read all items and 
property information, it uploads the prepared result ffle 2 
(1605) to the upper manager system (S106) and then 
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wails again for the uploading of the result file 1 (1606) 
from the lower-layer system (S101). 
[0031] At this moment, the state of the DB is as 
shown in FIG. 16. FIG. 16 shows that the property infor- 
mation about item C, item D, and item E of the result file s 
1 (1606) are reflected on the DB, and item A, item B, 
and item C have been uploaded to the upper system. 
[0032J Because the attribute of item C is the com- 
mon item, it is reflected (updated) on the DB and 
uploaded to the upper system, thereby preventing the io 
duplication of item C from being occurred. Thus, the 
above-mentioned method prevents data of any same 
item between the manager system and the managed 
system from being transferred in a duplicated manner, 
thereby enhancing the efficiency of the data transfer. 15 

Embodiment 2: 

[0033] The processing to be performed is generally 
in the same manner as that of the embodiment 1, 20 
except for the implementation method and merge-proc- 
ess. Therefore, the following describes mainly Merger- 
Process with reference to the state transition diagrams 
shown in FIGS. 18 and 19 and the flowchart shown in 
FIG. 20. The other processing will be described only in 25 
the portions different from those of the embodiment 1. 
Now, referring to FIG. 18, this system attaches an oper- 
ation flag to each item to be downloaded. To this opera- 
tion flag indicating operation status, either "A" indicative 
of addition or "D" indicative of deletion is set (1 805). 30 
[0034] The upper manager system stores the infor- 
mation edited in edit-process of items (processing for 
storing operation history is added behind each opera- 
tion processing described in the flowcharts shown in 
FIGS. 10 and 1 1) and adds the operation flag to each 35 
item in the item file (1805) to be downloaded upon com- 
pletion of edit-process (only the items manipulated in 
S304 of FIG. 10 are extracted and item adding process- 
ing is performed for the item preparing processing). 
[0035] As shown in FIG. 18, if items are added, "A" 40 
is attached to item D and item X to be added and "D" is 
attached to item A to be deleted. First, referring to FIG. 
20, when the item file is downloaded from the upper 
manager system in download-waiting state (S201), this 
system reads the operation flag and its item (S202). If 45 
the operation flag is deletion ("D") and the attribute of 
this item is the item managed by upper system p "), this 
system deletes the item from the DB and reads a next 
item (S204, S205. S208, A). 

[0036] If the operation flag is deletion ("D") and the so 
attribute is the common Hem ("2"), this system changes 
the attribute from the common item to the item managed 
by this system ("0") and reads a next item (step S204, 
S205, S206, S209, A). If the operation flag is addition 
("A") and there is no item, this system adds an item to ss 
the DB, sets the attributes of this item to the item man- 
aged by upper system ("l"), and reads a next item 
(S204, S210, S212, A). 



[0037] If the operation flag is addition ("A") and the 
attribute of the item existing in this system is the item 
managed by this system ("0"), this system sets the 
attribute of this item to the common item ("2") and reads 
a next item (S204, S210, S21 1 , S213, A). Then, for the 
other combinations of statuses than those mentioned 
above, this system does nothing but reading a next item 
(A). 

[0038] Having read all items, this system down- 
loads the item file that was received from the upper 
manager system to ail the submanager systems and 
managed systems in the lower layer connected thereto 
without change (S207) and waits for the downloading of 
another item file from the upper manager system (S207 
toC). 

[0039] This series of processing operations results 
in a table whose status shown in FIG. 19. FIG. 19 shows 
that item A deleted by the upper manager system and 
item D and item X added by the upper manager system 
are downloaded, the downloaded items are merged 
with the items held in the lower manager system, item D 
is newly added as the item managed by upper system, 
and the attribute of item X is changed to the common 
item. 

[0040] Thus, the second embodiment prevents a 
same item from being transferred in a duplicated man- 
ner and requires only a constant size of the item file to 
be downloaded which is a difference equivalent to the 
change made to the file. 

Embodiment3: 

[0041] In the embodiment 1 and the enixxfiment 2, 
the same items are managed by use of attribute infor- 
mation in each manager system. In the embodiment 3, 
each manager system has only the items that are man- 
aged by this system (on its own) only and has no 
attribute information, and each of the managed systems 
holds a requirement system (the program configuration 
for the embodiment 3 is the same as that of the embod- 
iment 1). 

[0042] First, merge-process will be described with 
reference to the flowchart shown in FIG. 24 and the sta- 
tus transition diagrams shown in FIGS. 22 and 23. rt is 
assumed that the following description is made with ref- 
erence to the lower manager system shown in these 
transition diagrams. In the initial state, this system is 
waiting for the downloading from the ipper manager 
system or the manager system (S401). 
[0043] The states of the items in the DB of each 
manager system are as shown in FIG. 22. For the sys- 
tem names, "SYSTEM" is set to the upper manager sys- 
tem and "SITE" to this lower manager system. The 
upper system holds items A, B, and C and this system 
holds items C, D, and E. 

[0044] Each item file to be downloaded is com- 
posed of items and manager system names for manag- 
ing these items as shown in FIG. 23. When an item file 
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1 (2305) has been downloaded from the upper manager 
system to this system in the download-waiting state 
($401), this system reads an Kern and its manager sys- 
tem name from the downloaded file (S402). 
[0045J « the read item is found also in the items s 
managed by this system (S404), this system adds the 
name of this system as a manager system to the dupli- 
cating name and its manager system name and writes 
the result to an item file 2 (2307) to be downloaded to 
the lower-layer system (S408). If no duplicating item is 10 
found, this system writes the items and their manager 
system names to the item file 2 (2307) without change, 
to be downloaded to the lower-layer system (S405). 
Having read all items (S403), this system extracts the 
items managed by this system that are not duplicating, is 
adds the name of this system to each of these items as 
the manager system name, writes these items to the 
item file 2 (2307) to be downloaded to the lower-layer 
system (S406), downloads the prepared item file 2 
(2307) to the lower-layer system (S407). and waits for 20 
the downloading of the item file 1 (2305) from the upper 
manager system (S401 ). 

[0046] FIG. 23 shows the downloading of the item 
files. Because item C is duplicated in both the upper 
manger system (SYSTEM) and the lower manager sys- 25 
tern (SITE), system names "SYSTEM" and "SITE" are 
set as manager system names. Each managed system 
holds the item file in the form of an item file to be down- 
loaded (in other words, the managed system holds the 
information about which item is to be returned to which 30 
manager system). 

[0047] When property information has been input- 
ted at the managed system, a result file is prepared in 
combinations of item, property information, and man- 
ager system name. The prepared result file is uploaded 35 
to the upper system of the managed system. The follow- 
ing describes update-process with reference to the flow- 
chart shown in FIG. 26 and the status transition diagram 
shown in FIG. 25. 

[0048] In the initial state, this system (SITE) is wait- ao 
ing for the uploading of a result file 1 (2505)(SS01) from 
the system immediately below. When the result file 1 
(2505) has been uploaded, this system opens it and 
reads the items, property information, and manager 
system names for one entry (S502). as 
[0049] if the name of this system is included in the 
manager system names of that entry (S504), this sys- 
tem updates the property information in its DB (S507), 
deleting the name of this system from the manager sys- 
tem names (S508). If another system name exists in the so 
manager system names (S509), this system writes the 
entry with the name of this system removed to a result 
file 2 (2507) to be uploaded as a result file to its upper 
manager system (S505). 

[0050] H the name of this system is not included in ss 
the read entry from the beginning, this system does not 
update the entry and writes the entry as it is to the result 
file 2 (2507) (S505). Upon reading all entries (S503). 



this system uploads the prepared result file 2 (2507) to 
Hs upper manager system (S506) and waits again until 
the result file 1 (2505) is uploaded from its lower-layer 
system (S501). 

[0051] FIG. 25 shows the flow of the result files, in 
which property items A, B, C, D, and E are uploaded as 
a result from its lower-layer system and this system 
(SITE) updates its DB with respect to items C, D, and E, 
uploading the result file containing items A, B, and C to 
its upper manager system (SYSTEM). 
[0052] Because item C is common to this system 
and its upper system, this system updates its DB and 
uploads the result file, thereby preventing the duplica- 
tion of item C from occurring. It should be noted that 
edit-process is executed only to edit the items of this 
system and therefore no special processing is exe- 
cuted. For this reason, the description of edit-process is 
skipped. 

[0053] Thus, the embodiment 3 prevents the dupli- 
cated transfer of items common to the manager system 
and the managed system to realize efficient data trans- 
mission in a method different from those of the embodi- 
ments 1 and 2. 

Embodiment 4: 

[0054] This embodiment, in addition to the capabili- 
ties of embodiment 1, provides a capability of allowing 
each submanager system to define in advance default 
items and their property information. The following 
describes this method with reference to FIGS. 27 
through 29. 

[0055] FIG. 27 shows the initial states of the man- 
ager system and submanager systems in which the 
manager system of the head office prepares items 
"business office code", "department code", "name", 
"extension number", the submanager system of the 
business office defines "business office code" and the 
submanager system of the department defines "depart- 
ment code" as defaults. Addition and deletion of default 
items can be executed as a part of edit-process. 
[0056] FIG. 28 shows a processing flow in which an 
item file is downloaded to each system. An item file 
(2805) is downloaded from the manager system of the 
head office to the submanager system of the business 
office. The submanager system of the business office 
compares the item names in the item file with the default 
item names. If a matching name is found, the subman- 
ager system stores the matching item and its property 
information into the default DB. Then, the submanager 
system of the business office downloads an item file 
(2808) of "department code," "name", and "extension 
number" with "business office code" removed therefrom 
to the submanager system of the department. The sub- 
manager system of the department processes "depart- 
ment code" in the same manner and downloads an item 
ffle (281 1) composed of "name" and "extension number" 
and sets property information for that item. It should be 
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noted that the items and their property information 
stored in the default DB are deleted when new items are 
downloaded from the upper manager system. 
[0057J FIG. 29 shows the processing flow in which 
result files are uploaded. When property information is s 
inputted in the managed system, the managed system 
uploads a result file to the suJbmanager system of the 
department. The submanager system of the depart- 
ment adds the item and property information in the 
default DB to the result file and uploads it to the sub- io 
manager system of the business office. The subman- 
ager system of the business office carries out the same 
processing as described above, uploading the result file 
to the manager system of the head office, the result file 
storing the property information of all items. The current is 
embodiment can be actually implemented by adding 
particular processing to the processing flow of embodi- 
ment 1. 

[0058] First, in merge-process, this system adds 
processing in which the contents of the default DB are 20 
all deleted upon downloading of an item file (this 
processing is added under S003 of FIG. 15). This sys- 
tem checks the downloaded items for an default item. 
After entering property information of the same time as 
the default item into the default DB. This system adds 2s 
processing in which no file is downloaded to the lower- 
layer system (this processing is added under S005 of 
FIG. 15). Then, when the information is uploaded in 
update-process, this system adds processing in which 
the items and their default values are additionally writ- 30 
ten to the result file to be uploaded to the upper man- 
ager system (this processing is added so that it is 
executed when the file has all been read in S103 of FIG. 
17). Thus, embodiment 4 can reduce the amount of 
data transfer by the items defined by default. 35 

Embodiment 5: 

[0059] In embodiment 5. this system determines in 
the method of embodiment 4 whether there is any 40 
default item in the items downloaded by the subman- 
ager system to this system. If a default Hem is found, 
this system enters the property information of the same 
item into the default DB. Then, if there is no more item 
to be downloaded to the manager system or the man- as 
aged system in lower layer (if this system has set the 
default items for all items), this system extracts the 
items and property information from the default DB, pre- 
pares a result file, and uploads it to the upper manager 
system. so 
[0060] In the actual implementation method, 
embodiment 5 can be realized by adding particular 
processing to the flow of embodiment 1 on which the 
capabilities of embodiment 4 are implemented. In 
merge-process, this system determines whether there 55 
is any item file which is downloaded to the lower-layer 
manager system or the managed system. If such an 
item file is found, this system downloads it. If no such 



item file is found, this system adds processing in which 
all contents of the default DB are extracted, a result file 
is prepared to be uploaded to the upper manager sys- 
tem, and uploads the prepared result file to the upper 
system (this processing is added under S008 of FIG 
15). 

[0061] The method of embodiment 5 can prevent 
the data transfer from the submanager system which 
has completed the input of property information by 
items defined by default to the managed system. 
[0062] In addition, this method enhances the effi- 
ciency of data transfer over one route of network in a 
hierarchical network environment, which in turn realiz- 
ing the efficient data transfer over the entire network. 
[0063] While the preferred embodiments of the 
present invention have been described using specific 
terms, such description is for illustrative purposes only, 
and it is to be understood that changes and variations 
may be made without departing from the spirit or scope 
of the appended claims. 

Claims 

1. A method of data transfer in a hierarchical network 
comprising the steps of: 

receiving first data including an item from an 
upper system; 

updating attribute information corresponding to 
said item held in a current system and adding 
second data held in said current system to said 
first data: and 

sending said first data and said second data to 
a lower system. 

2. The method of data transfer as claimed in claim 1 , 
further comprising the steps of: 

if said item included in said received first data 
exists in said current system, updating said 
existing item; 

changing attribute information for said item 
held in said current system to a value indicative 
of common data; 

if said item does not exist in said current sys- 
tem, adding said item to said current system; 
and 

changing said attribute information for said 
item held in said current system to a value 
indicative of data which is prepared by said 
upper system. 

3. The method of data transfer as claimed in claim 1 , 
still further comprising the steps of: 

receiving at least one of edit requirements for 
addition and deletion of said item; and 
changing attribute information for said item 
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held in said current system according to the 
change of said item and item content of said 
current system corresponding to said item. 

4. A method of data transfer in a hierarchical network s 
comprising the steps of: 

receiving an item and data stored in first data 
coming from a lower system; 
if said item exists in a database of said current io 
system and attribute information corresponding 
to said item indicates a value managed by an 
upper system, reading data included in said 
first data and storing the read data into second 
data; and 1S 
sending said second data to said upper sys- 
tem. 

5. The method of data transfer as claimed in claim 4, 
wherein, if said attribute information corresponding 20 
to said item indicates a value not managed by said 
upper system, said data is stored in said current 
system. 

6. The method of data transfer as claimed in claim 1 , 2s 
wherein said first data includes an operation flag 
indicative of either one of item addition or item dele- 
tion, and addition of said item to said current sys- 
tem is determined on the basis of said operation 
flag and information indicative of existence or 30 
absence of said item in said current system. 

7. The method of data transfer as claimed in claim 1 , 
wherein said second data holds manager system 
information indicative of that said item is the data 35 
associated with said current system and whether 
said item is processed or not is determined on the 
basis of said manager system information. 

8. A method of data transfer in a hierarchical network 40 
comprising the steps of: 

receiving from a lower system an item and data 
included in first data and manager system 
information indicative of whether said item is 45 
the data associated with a current system; 
if said manager system information is the data 
associated with said current system, updating 
a content of an item held in said current system 
by use of said data; 50 
if said manager system information has infor- 
mation indicative of another system, deleting 
the information indicative of said current sys- 
tem; 

forming second data by said item, said data, 55 
and the manager system information with the 
information indicative of said current system 
deleted; and 



sending said second data to an upper system. 

9. A method of data transfer in a hierarchical network 
comprising the steps of: 

receiving first data from a lower system; 
forming second data by an item corresponding 
to default information held in a current system 
and data included in said first data; and 
sending said second data to an upper system. 

10. A method of data transfer in a hierarchical network 
comprising the steps of: 

receiving first data from an upper system; 
storing into a current system an item included 
in said first data, said item corresponding to 
default information held in said current system; 
storing data with said item corresponding to 
said default information of said current system 
deleted from said first data into second data; 
and 

sending said second data to a lower system. 

1 1. The method of data transfer as claimed in claim 1 0, 
wherein data to be sent to said upper system forms 
said second data when there is no more data to be 
sent to said lower system after deleting said item 
corresponding to said default information of said 
current system from said first data and said second 
data is sent to said upper system. 

12. A data transfer apparatus for use in a hierarchical 
network comprising: 

a receiving block for receiving first data includ- 
ing an item from an upper system; 
a merge processing block for updating attribute 
information corresponding to said item and 
held in a current system and adding second 
data held in said current system to said first 
data; and 

a sending block for sending said first data and 
said second data to a lower system. 

13. The data transfer apparatus as claimed in claim 12, 
wherein said merge processing block updates said 
existing item, if said item included in said received 
first data exists in said current system; changes 
attribute information for said item held in said cur- 
rent system to a value indicative of common data; 
adds said item to said current system, if said item 
does not exist in said current system; and changes 
said attribute information for said item held in said 
current system to a value indicative of data which is 
prepared by said upper system. 

14. The data transfer apparatus as claimed in claim 12, 
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further comprising: 

an edit processing block for receiving at least 
one of edit requirements for addition and dele- 
tion of said item and changing attribute infer- s 
mation for said item held in current system 
according to the change of said item and item 
content of said current system corresponding 
to said item. 

w 

15. A data transfer apparatus for use in a hierarchical 
network comprising: 

a receiving block for receiving an item and data 
stored in first data coming from a lower system; is 
an update processing block for, if said item 
exists in a database of a current system and 
attribute information corresponding to said item 
indicates a value managed by an upper sys- 
tem, reading said data included in said first 20 
data and storing the read data into second 
data; and 

a sending block for sending said second data to 
said upper system. 

25 

16. The data transfer apparatus as claimed in claim 15, 
wherein, if said attribute information corresponding 
to said item is a value indicative of common man- 
ager item, said updating processing block stores 
said data into said current system. 30 

17. The data transfer apparatus as claimed in claim 12, 
wherein said first data includes an operation flag 
indicative of either one of item addition or item dele- 
tion, and said merge processing block determines 35 
whether or not to add said Hem to said current sys- 
tem on the basis of said operation flag. 

18. The data transfer apparatus as claimed in claim 12. 
wherein said second data holds manager system 40 
information indicating that said item is data associ- 
ated with said current system and said merge 
processing block determines whether or not to 
process said item on the basis of said manager sys- 
tem information. as 

19. A recording medium readable by a computer stor- 
ing a program for executing the data transfer 
method cited in claim 1. 

so 

20. A recording medium readable by a computer stor- 
ing a program for executing the data transfer 
method cited in claim 2. 
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